mackerel으로 인프라를 감시해보자 – 4(그 외의 모니터링과 팁)

매커렐(Mackerel)을 이용하여 인스턴스의 프로세스와 포트, 외부 URL 감시를 하는 방법을 알아보겠습니다

#한국어블로그

#Mackerel

Lee Sujae

2021.08.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

지난번 글에서 로그와 데이터베이스 감시를 설정해보았습니다.
마지막으로 이전 글들에서는 설명하지 않았던 프로세스/포트/외부 URL 감시를 설정해보겠습니다.
그리고 이외의 팁을 공유하고자 합니다.

다양한 감시하기

아래의 감시들은 기본적인 설정이 끝났다는 가정하에 진행합니다.

프로세스 감시하기

특정 프로세스의 실행이 아닌 프로세스의 종료가 발생한 경우 경보가 발생합니다.
우선 공식 체크 플러그인을 설치하여야 합니다.
공식 문서를 참고하여 각 OS에 맞춰 설치합니다.
(이미 설치가 되어있다면 다음으로 넘어갑니다)

감시 항목의 설정은 로그 모니터링과 마찬가지로 설정 파일에 옵션을 추가하고 에이전트를 재기동하는 것으로 끝입니다.
에디터로 설정파일을 열어 다음과 같은 내용을 추가합니다.
(매커렐의 설정 파일은 리눅스라면 /etc/mackerel-agent/mackerel-agent.conf
윈도우의 경우 C:\Program Files (x86){또는Program Files}\Mackerel\mackerel-agent 에 있습니다.)

[ plugin.checks.check_nginx ] 
command =  [ "check-procs" ,  "--pattern" ,  "nginx" ]

윈도우의 경우 .exe를 제외한 프로세스 이름을 지정해주시면 됩니다.
로그 모니터링과 마찬가지로 커스텀 체크의 다른 옵션들을 사용할 수 있으며
프로세스 체크만의 옵션으로는 초과/미만 프로세스 수 체크와 실행 유저 지정이 있습니다.

# -w 초과하면 warning -c 초과하면 critical -W 미만이면 warning -C 미만이면 critical --user 실행하는 유저 지정
[ plugin.checks.check_nginx ] 
command =  [ "check-procs" ,  "--pattern" ,  "nginx" , "-W" , "1" , "-C" , "1" , "-w" , "8" , "-c" , "10", "--user" , "nginx"]

포트 감시하기

체크 플러그인의 check-tcp를 이용하여 호스트와 포트 감시를 설정할 수 있습니다.
해당 호스트와 포트의 응답 시간을 기준으로 warning과 critical을 설정할 수 있습니다.

# 응답에 3초 이상이 걸리면 warning 10초 이상이면 critical
[ plugin.checks.tcp_httpd ] 
command =  [ "check-tcp" ,  "--hostname" ,  "localhost" ,  "--port" ,  "80" , "--warning " ,  "3 " ,  "--critical " ,  "10 " ]

HTTP 이외에도 몇 가지 잘 알려진 서비스의 경우에는 --service 옵션을 이용하여 포트 번호 등의 지정없이 해당 서비스의 감시를 설정할 수 있습니다.

[ plugin.checks.ftp ] 
command =  [ "check-tcp" ,  "--service" ,  "ftp" ,  "--host" ,  "localhost" ]

현재 --service 에 사용 가능한 값으로는 다음과 같습니다.

FTP
POP
SPOP
IMAP
SIMAP
SMPT
SSMTP

외부 URL 감시

http 또는 https에 대해 모니터링을 설정할 수 있습니다.
대시보드에서 사이드바의 Monitors에서 [New Monitor] -> [External Http monitor] 버튼을 클릭합니다.
필요한 각 항목에 값을 설정하고 생성 버튼을 클릭합니다. Scope와 Monitor Name 만 필수 설정 값이고 나머지는 옵션입니다.

Scope : http 또는 https를 선택하고 그 이후의 URL을 기입합니다.
Options : 응답 시간, 경보 규칙, 요청 헤더 등을 지정할 수 있습니다.
- HTTP Request Header : 요청에 임의의 HTTP 헤더를 지정할 수 있습니다.
- Response Body Check : 응답 본문에 지정된 문자열이 포함되어 있는지를 확인합니다. 지정된 문자열이 응답 본문에 포함되지 않은 경우 경보가 발생합니다
Certification expiration date monitoring : SSL 인증서의 유효 기간을 모니터링합니다. 유효 기간에서 남은 기간이 임계 값 아래로 떨어지면 경보가 발생합니다.

외부 URL 감시은 다음과 같이 작동합니다.

검사 간격은 1 분마다 고정됩니다.
다음 조건에서 오류로 인식하고 경고가 실행됩니다
- 상태 코드가 4xx 또는 5xx 계열의 경우
- 제한 시간 (15 초)이 된 경우
- SSL 인증서가 손상된 경우
- 응답 시간이 임계 값을 초과하는 경우 (임의 설정)
- 응답 본문에 문자열이 포함되지 않은 경우 (임의 설정)
- SSL 인증서의 남은 유효 기간이 임계 값을 밑돌고 있는 경우 (임의 설정)
2xx 계의 응답은 오류가 없는 정상적인 응답으로 인식합니다
리디렉션 후속에 대한 동작 설정을 변경할 수 있습니다
- 추가 설정을 하지 않는 경우, 3xx 계의 응답은 오류가 없는 정상적인 응답으로 인식합니다
- 추가 설정을 할 경우 응답 헤더의 내용에 따라 리디렉션합니다
- 3 회 이상 리디렉션 오류가 발생 경고 알림이 실행됩니다

다양한 팁들

실수로 매커렐 UI에서 호스트를 삭제해버렸을 때

AWS 통합(인테그레이션)이 되어 있으면 자동으로 다시 추가되지만 매커렐 에이전트만 등록되어 있으면 다시 추가 되지 않습니다.

관리 ID가 삭제(퇴역, retirement)되고 같은 ID를 가진 파일을 다시 작성하면 감시 재개는 가능한가?

관리 ID가 삭제(퇴역, retirement)된 시점에서 관리 ID는 재이용 불가능합니다.

Cloud Watch의 사용자 지표를 매커렐에서 볼 수 있을까?

볼 수 없습니다.
AWS 통합은 Cloudwatch에서 일반 지표를 5분 간격으로 수집하고 있기 때문에 볼 수 없습니다.
매커렐의 사용자 지표를 따로 설정해야합니다.

똑같은 내용의 로그 감시, 외부 URL 감시 등을 다시 설정했는데 과거의 기록은 볼 수 있을까?

통계로 따로 저장해두지 않기 때문에 검사 이력을 추적 할 수는 없습니다.

기본 API 키는 삭제 가능?

삭제는 가능하지만 write 권한이 있는 키 하나는 유지해야합니다.

유저를 등록할 때 SSO(SAML)로 대응할 수 있을까?

아직까지 초대는 기본적으로 이메일 주소 뿐 이므로 SSO 로그인은 할 수 없습니다.
하지만 로드맵을 참고해보니 지원 예정으로 되어 있습니다.

Redshift를 감시할 때의 주의점

우선 AWS 통합으로만 모니터링을 설정할 수 있습니다.
따라서 AWS 통합은 단순이 Cloudwatch의 지표를 취득하고 있을 뿐이므로 지표가 Cloudwatch에 put되지 않는 시간이 길어도 매커렐에서는 별도의 경고가 발생하지 않습니다.
또한 지표가 취득되지 않는 것으로는 경보가 발생하지 않기 때문에 이걸로 서비스의 상태를 파악할 수는 없습니다. 따라서 서비스의 상태 파악을 위해선 Redshift의 헬스 체크 지표로 파악하여야 합니다.